home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 9618 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.3 KB  |  72 lines

  1. Newsgroups: comp.lang.modula3,comp.lang.c++,comp.lang.java
  2. Path: news.u.washington.edu!uw-beaver!news
  3. From: Brian Bershad <bershad>
  4. Subject: Re: Java closer to Modula-3 than to C++
  5. Content-Type: text/plain; charset=us-ascii
  6. Sender: news@beaver.cs.washington.edu (USENET News System)
  7. Content-Transfer-Encoding: 7bit
  8. Organization: Computer Science & Engineering, U of Washington, Seattle
  9. Message-ID: <DnoB9p.MAI@beaver.cs.washington.edu>
  10. X-Url: news:1996Mar1.143408.951@friend.kastle.com
  11. References: <31308FE2.167E@sophia.inria.fr> <1996Feb26.192508.2614@friend.kastle.com> <DAGENAIS.96Feb29113254@hagen.vlsi.polymtl.ca> <1996Mar1.143408.951@friend.kastle.com>
  12. X-Mailer: Mozilla 1.1N (X11; I; OSF1 V3.2 alpha)
  13. Mime-Version: 1.0
  14. X-Nntp-Posting-Host: twirl.cs.washington.edu
  15. Date: Sun, 3 Mar 1996 04:03:25 GMT
  16.  
  17. rich@kastle.com (Richard Krehbiel) wrote:
  18. >dagenais@hagen.vlsi.polymtl.ca (Michel Dagenais) wrote:
  19. >
  20. >>In article <1996Feb26.192508.2614@friend.kastle.com> rich@kastle.com (Richard Krehbiel) writes:
  21. >
  22. >>   Oh, I think it's clear that C++ gets it's success from C.  C #includes
  23. >>   and libraries can (almost always) be called upon in C++ programs.
  24. >>   Nothing like that can be said of Modula-3 or Java.
  25. >
  26. >>Well, too bad i did not know i could not do it. I have called X libraries,
  27. >>unix system calls, the gnu dbm library, ODBC drivers... from Modula-3 without
  28. >>problem.
  29. >
  30. >Well, then you've managed the easy half of the battle.  Now get
  31. >Modula-3 to include C header files and make proper sense of them.
  32. >
  33. >--
  34. >Richard Krehbiel, Kastle Systems, Arlington VA USA
  35. >rich@kastle.com (work) or richk@mnsinc.com (personal)
  36. >
  37.  
  38. Actually, for a bunch of reasons, you don't want this functionality.
  39. Wilson already mentioned the problem of alignment disparity. Other problems
  40. you have when blindly going from M3 to C or the other way are:
  41.     - traced refs. if C puts a traced ref into its untraced heap,
  42.     you'll get into trouble.  We've addressed this problem by 
  43.     adding a StrongRef interface that can be used to prevent the
  44.     compiler from collecting OR moving a ref before it gets passed
  45.     to C.
  46.     - <*EXTERNAL*> functions, when declared in safe M3 interfaces
  47.     are in no way guaranteed to be safe.  By this, I mean that
  48.     anyone can write a safe interface that for example, lets you call
  49.     an integer over in C.  Bad news.  We've addressed this problem
  50.     by disallowing the use of <*EXTERNAL*> in safe interfaces.  If you
  51.     call into C, then you need to know what you're doing is likely to
  52.     be unsafe and you should advertise that to clients of the interface.
  53.  
  54. We have to deal with this kind of stuff all the time in SPIN, since we 
  55. rely on vendor device drivers for our kernel.  The basic way we deal
  56. with this is by writing wrapper services for all the EXTERNAL c functions.
  57. It's almost always the case that the wrappers have to do something semantically
  58. interesting before calling out to C.  
  59.  
  60. None of this argues that you can't use C from M3; you just have to do
  61. it carefully.  By analogy, M3 doesn't prevent you from designing unsafe
  62. implementations, you just have to be careful in how and when you use
  63. those implementations (think of all your C code as a kind of unsafe M3
  64. implementation and everything makes sense).  
  65.  
  66. Finally, C++ has no inherent advantage in integrating with C. If you use
  67. any of the advanced constructs in C++, you're going to get in trouble when
  68. you call into C unless you're careful. 
  69.  
  70.     Brian
  71.  
  72.